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ABSTRACT 



The properties and characteristics of a recently developed set of 
hardwired Register Transfer Modules (RTMs), which can be interconnected 
to perform the functions of a digital computer, are presented. To 
illustrate the value of this higher level of computer design, sets of 
simulated RTMs were combined to carry out the operations of both a 
general purpose digital computer, and a digital computer designed to 
perform specific tasks. 

The general purpose computer capabilities were demonstrated by 
interconnecting modules to perform the various functions of a FORTRAN 
machine. The specific task application was shown by constructing a 
system of modules to perform a triangulation algorithm. This applicatior 
also demonstrates how the concept of modularization could be applied to 
a 1969 proposal by the Navy for a single, modularized airborne computer 
system known as the Advanced Airborne Digital Computer (AADC). 
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I. INTRODUCTION 



In the design of digital computers, the solution to most problems 
is carried out at the basic hardware level - that is, the NAND and NOR 
gate level of operations. Problem formulation at this level, however, 
is very difficult due to the significant effort required to manipulate 
the large number of logical equations associated with these gates. Sub- 
sequently, most problem formulation and conceptualization is accomplished 
at the level of register transfer operations. It is at this level that 
control signals are set up to cause information to be transferred between 
i^egisters. 

There have been various attempts to write logical design simulators 
and to carry out the detailed sequential and combinational logic designs 
from this register transfer level. Until recently however, there has 
been little or no attempt to design a common set of hardware modules to 
be taken as primitive operations based on register transfers in the 
same way that various flip-flops and NAND and NOR gates have been uti- 
lized. Bell and Grason have undertaken this task in Reference [1]. Their 

efforts have resulted in the design of a set of register transfer modules 
(called RTMs) which are used as a basis for digital systems design and 
have the property of allowing a digital system to be specified without 
the usual switching circuit design. These modules are the basis for the 
concepts presented in this paper. 

Reference [2] discusses the concept of an Advanced Avionics Digital 
Computer (AADC) proposed in 1969 as a single computer design to satisfy 
the majority of Navy airborne computing requirements in the 1975-1985 
time period. The objective forwarded in this proposal is the use of one 
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set of standard, efficiently designed hardware modules which would allow 
flexibility in configuring a computer organization for specific func- 
tional applications. The ultimate objectives, of course, are increased 
reliability and improved cost effectiveness by the use of "throw-away" 
module repair techniques. 

This paper presents a set of simulated register transfer modules, 
written in ALGOL, which can be combined to perform either as a specific 
task computer or in a general purpose configuration thus demonstrating 
the feasibility of combining hardware modules in this manner. In 
addition, a simulation program which combines these modules to solve 
a simple triangulation problem is presented as evidence of their possible 
use in solving the AADC problem. 
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II. NATURE OF THE PROBLEM 



A. SELECTION OF REGISTER TRANSFER MODULES 

The formulation of algorithms which, when executed by hardware, 
solve the computer logical design problem is a concern of most digital 
system design engineers. Figure 1 of Reference [1] presents a comparison 
of the solutions to the various design problems using programming, con- 
ventional logic design and Register Transfer Modules. Each of these 
three processes have the same goals namely: to construct a program for a 
machine, or to construct a hardwired machine, which will execute an 
algorithm to solve the problem. The fundamental results of the compari- 
son is that RTMs can be considered as a set of basic components for con- 
structing hardwired algorithms -- that is, they are the basic components 
for the design of digital systems. 

There is a wide range of problem areas in which the RTM approach 
may simplify the design process. For example, in computer related work, 
one might use the modules as a controller for a simple device such as a 
card reader, requiring only a few control states. More complex tape and 
disk controllers with many states would have a higher design payoff. 

The RTM approach seems particularly appropriate for installations 
with several "old" computers to which special devices, such as communica- 
tions lines are attached. It is intended that the modules discussed here 
will make the design of special purpose processers practical (Ref. 1). 

The hardwiring of general purpose computers is also an interesting 
application of this design approach. 

The preliminary design problems of this model were: defining a set 
of modules to carry out the desired algorithms; formulating the 
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interconnecting structure of the modules so that various classes of 
algorithms could be solved; and, selecting a simulation language to check 
the design. 

In defining a set of modules, consideration was given to the design 
constraints listed in Reference [1]. They are: 

1. Hardware Technology Constraints. This set of constraints 
dictates the hardware from which the modules are constructed. 

2. Problem Constraints. Each digital system problem can be 
characterized by its hardware (and/or programming) requirements. For 
example, these constraints include word length, number base, operation 
types, etc. This set of constraints is roughly a measure of the problem 
size. 

3. User Constraints. These constraints are both objective and 
subjective because they reflect how a human user views tfie modules (e.g., 
cost, ruggedness, reliability, ability to debug) for solving a particular 
class of problems. 

4. Internal Constraints. Constraints coming from the organization 
and individuals building the modules (e.g., corporate profit and 
fabrication technology). 

The constraints on hardware technology are mostly fixed and usually 
dictated by integrated circuit technology. The only hardware related 
constraint affecting this project however, was word length. Since most 
computers use 8, 12 or 16 bits, a word length of 16 bits was chosen to 
minimize any conflict in this area. Additional hardware constraints 
which do not come into play in this project are discussed in detail in 
Reference [1]. 

The constraints which were most significant in development of this 
» 

model were of the second type, i.e., problem dictated. Computer problems 
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are usually measured by the number of statements (control operations) 
they contain, the number of register operations they perform, or the 
amount of memory they require. The RTMs simulated in this project were 
designed for up to 100 hardwired control steps, multiple arithmetic 
units, and a small read-write memory of about 100 words. The simulated 
modules were thus appropriately constrained. 

Although cost, circuit structure, and other user dictated and 
internal constraints bear heavily on the design of actual hardwired RTMs, 
they are not considered significant to the construction of this model. 

It is significant to note that similar modules are being built and 
additional discussion of the constraint areas concerning the actual RTMs 
is available in Reference [1]. 

The characteristics of the individual Register Transfer Modules 
used in this model are discussed in Section III, 

B. AN RTM COMPUTER DESIGN 

A valuable and remunerative use for the RTM system is in the 
simplicity of designing either special purpose or general purpose 
computers. An example is a small stored program computer which was 
designed by Bell and Grason using RTM modules, and was roughly equivalent 
to the Digital Equipment System's PDP-8 (Ref. 1). The process of specify- 
ing this machine using both ISP (Instruction Set Processor) and RT 
(Register Transfer) descriptions took approximately six manhours. The 
computer was wired, and aside from minor connection problems in the RTMs, 
the computer operated essentially when power was applied since there 
were no logic errors. The computer was designed for an actual applica- 
tion which had about 300 constants, 600 control steps and about 16 
variables. An alternative approach would have been to hardwire the 600 
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control steps directly, but this would make the model more costly and 
less flexible. The computer had only 24 simple and 16 decision modules. 
Since the price ratio of a hardwired control to a stored control is 
approximately 10:1, it was cheaper to use RTMs to build the computer and 
then let the computer program execute the control steps. According to 
Reference [1], the overall cost of an actual RTM implementation appears 
to be at least a factor of 4 cheaper than some of the alternative 
register transfer approaches to computer design. 

C. AADC CONCEPT 

The procedure within the Navy has been to specify computational 
requirements for a new system design and then, generally, to procure 
either a special purpose computer or a near optimum general-purpose 
machine which will satisfy the requirements. This procedure generates 
a situation where a relatively large and diversified group of machine 
hardware and software packages, and associated repair components must 
be maintained in inventory. Not only are these machines generally not 
adaptable or expandable for use in different functional areas, but the 
development cycle for a new machine tends to become lengthy and costly. 
This procedure provides the motivation for the development of a single, 
highly flexible, and functionally adaptable computer design - the 
Advanced Avionics Digital Computer. 

The possible use of Register Transfer Modules to fill the design 
requirements of the proposed avionics system was actually the inspira- 
tional motivation for this thesis. It was desired to demonstrate the 
use of these modules in this application.. 
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III. THE MODEL 



The RTM system modeled in this project consists of eight types of 
Register Transfer Modules and a method of interconnecting modules via a 
common bus which carries data and timing interlock signals between the 
modules. Some of the modules connect to a bus in order to transfer data, 
and the remaining modules "control" when data is to be transferred. The 
interconnecting structure of the modules used in this project are taken 
from Bell and Grason's model. This structure is flexible and efficient, 
and since the type of structure used is not critical to this project, 
the use of an already proven structure was desirable. 

The Instruction Set Processor language as used here is a language 
for describing the register transfer operations of the RTM's. The only 
parts of this language used in describing the modules are those commonly 
known to the digital systems engineer. The module types modeled in this 
project are: 

1. DM for memory. The DM (data memory) part is just the registers 
which hold data between statements; these essentially correspond to the 
variable declarations of a program. The operations on memory are 
usually just reading (-^M) and writing (M<-) . 

2. K for control. The K modules are responsible for the movement 
of data between modules by appropriately evoking operations on the DM 
(memory) types. The K modules are similar to the control structure of a 
program. They control the times at which various statements are evoked, 
and are also used to make decisions about which controls are to be 
evoked next. These modules are used to connect a sequence of operations 
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together as in a subroutine and to synchronize control when there is more 
than one operation taking place at a time. 

RTMs provide for two basic data types: booleans ( a single bit); 
and 16-bit two's complement integers. The 16 bits of a register, R, 
are denoted R<15:0> where the bit R<j> has the value 2'^. 

The bus carries the data between the registers for the various 
transfer commands. All memory modules connect to the bus for inter- 
register transfers. There are register interlock signals associated 
with data transmission to insure that the data on the bus is valid. The 
bus has storage for: the 16 data bits; an arithmetic overflow bit; and 
other signals to control the data transfer -- including the control 
signal to indicate that the function evoked has been completed. K 
modules connect to the bus and use the evoke function completed signal. 

In selecting a language in which to model the desired concepts, 
consideration was given to the particular languages available on the IBM 
360/67 installation at the Naval Postgraduate School, the availability 
and ease of bit operations within these languages, and the speed of 
compilation of the languages on this system. FORTRAN, ALGOL W and PL/1 
were the major algebraic languages available. ALGOL W was selected 
because the version of FORTRAN in use does not have bit operations and 
PL/1 is slower in compiling. 

A. BASIC MODULES 

There are four basic modules which are necessary to the construction 
of non-trivial digital systems: Ksimple, DMgpa , Kdecision and Kbus. 
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An operational description of each of these modules is given in the 
following paragraphs. Diagrams and additional information for these 
modules are available in Appendix A. 

Ksimple (Ks) is the basic module which evokes a function consisting 
of a data operation and a register transfer. When a Ksimple is evoked, 
it in turn evokes the operation function and then evokes the next K 
module. The data operation is basically the righthand side of an 
assignment statement, or the part read from a memory location, e.g., 

-«-X and -«-Y+Z. The register transfer part is the lefthand side of an 
assignment statement, e.g., Q<- or MA-^. The diagram for Ks with its two 
inputs and two outputs is: 



1 


1 evoke thi s 


control /ev 


Ks (Name of function 
to be evoked) 


evoke a function/evfn ^ 


^ evoked function complete/evfnc 




I evoke the next control function/evn 



The ALGOL simulation of the Ksimple module is shown in Appendix B. 

The DM (general purpose arithmetic)/qpa allows arithmetic function 
results (data operations) which have been performed on its two registers 
R1 and R2, to be written into other registers and locations (using the 
bus). A complete diagram is shown in Appendix A. Numbers are repres- 
ented in two's complement form. Results can also be transferred into 
R1 and R2 (Rl-«-, R2-e) . The complete list of data operations is shown in 
Appendix B. All bits of both registers Rl<15:0> and R2'15:0> are avail- 
able as booleans to be tested. Data can be shifted into the left and 
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righthand bits on /2 and *2 operations, respectively, in which case 
an overflow flag is activated. 

The ALGOL W simulation model for this project contains two general 
purpose arithmetic modules, GPA and GPA2. GPA is the main gpa and is 
designed to fulfill all the requirements of the gpa described in Bell 
and Grason's model. GPA2 is a more restricted version of the main gpa 
which is designed to handle small administrative tasks in the program. 

It has fewer data operations and operates synchronously with the main 
gpa using the same data bus. 

Appendix B contains a listing of the numbers assigned the various 
data operations which are performed in the GPA, and a listing of the GPA 
module. 

The Kdecision (Kd) module provides for the routing of control flow 
based on the condition of a boolean input. The diagram for Kd with its 
two inputs and two outputs is: 



boolean input 





evoke this control/ev 
r 


Kd (boolean input condition being tested) 


1 evn l/(evoke 


evn 0/(evoke next! 


X next if boolean 


if boolean! 


I is true 


is false i 



Each time a decision control is evoked, it in turn evokes one of the 
controls attached to it depending on whether the boolean input is true 
(a 1 ) or fal se (a 0) . 

The Kbus module requires a centralized control module for each inde- 
pendent data bus in the system. It has a register. Bus, which always 
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contains the result of the last register transfer that took place via 
the bus. Each bit of the bus is available as a boolean. As denoted in 
Reference [1], the bus module carries out the following functions: 

1. monitors all register transfer operations and supplies the 
evoke function completion control signal, evfnc, to indicate the 
requested function has been completed; 

2. provides for single step control by the user, thus, a push 
button can be used to step each register transfer operation and create 
the evoke function completed signal; 

3. provides for sense lights to be connected to the bus register 
so that data transfers which use the bus may be monitored. 

4. provides for a word source of zero, i.e., -<-0; 

5. multiple register transfers can be made in one statement A-eB-c-C-s-D 
(to reset A, B, and C); 

6. provides for a null operation v/hich allows data to be trans- 
ferred to the Bus register for testing, i.e., Bus-«-; 

7. forms the following boolean functions which are available after 
each control step using the bus: 

Bus <15:0> = 0 (detects whether the last word 

transferred was a zero) 

Bus <15>,Bus<14>,. . . , (16 booleans, 1 for each bit) 

Bus <0> 

Overflow (the register arithmetic operation 

caused an overflow, e.g., -«-A+B, 

<-Ax2) 

8. resets all modules when power is applied; 

9. provides a manual start signal to evoke the first control; 

10. provides electrical termination. 

Obviously, it is not necessary to simulate within the simulated 
bus model all of the above functions as some of them are merely direct 
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connections. Functions 1,2, 4, 5, 6, and 7 were therefore the primary 
objective of the simulation program. 

The four aforementioned modules are essential for a small 
non-trivial computer system. Some of the additional modules which are 
available and add variety and sophistication to the RTM model are: 

K(branch) - allows control to be passed to a number of controls 
in parallel (simultaneously) 

K(seria1 merge) - allows several control sequences to terminate 
in series and form a single control evoke. 

K(paral1el merge) - allows several control sequences to terminate 
in parallel and form a single control evoke. 

K(manua1 evoke/me) - provides an interface betv/een the RTM system 
and the human user. 

K(clock) - generates a control signal at periodic intervals. 

K(delay) - delays the next evoke signal for a period of time. 

There are some 20 types of -Register Transfer Modules presently 
available and described in Reference [1], and it is considered that this 
number will increase as technology advances and various tasks evolve. 

A complete listing of all modules available is given in Appendix A. 

The following is a list of the modules that were written, tested 
and combined in this project to simulate the various digital computer 
capabilities. The four basic modules have already been discussed. The 
remaining modules are described in subsequent sections. 
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BASIC 


ARITHMETIC 


FLOATING POINT 


TRIGONOMETRIC 


KSIMPLE 


ADDER 


FADD 


SINANG 


KBUS 


KTIMES 


FSUB 


ARCSIN 


KTEST 


KDIVIDE 


FDIVIDE 


ANGTAN 


GPA 


Kbranch 


FTIMES 






Kboolean 






B. ARITHMETIC 


MODULES 







In any computer, certain basic arithmetic operations are required 
which are more complex than those simple data operations performed in 
the gpa module. Some of these operations are add, subtract, multiply, 
divide, etc. In order to demonstrate the capability of the RTM system, 
these arithmetic operation modules were constructed using basic system 
hardware and other RTM system modules already developed. 

Appendix C presents a diagram of a 16 bit adder/subtractor which 
performs either addition or subtraction depending on a flag in the call- 
ing module, using the logical AND/OR operations on each of the bits. 

The operation of the adder is similar to that described for a full 
adder in Reference [3]. This adder would normally be contained in the GPA 
but in the simulation model it was constructed separately and called from 
the GPA. 

A 16 bit integer multiplier is shown in Appendix D. The diagram 
includes two parts: the K modules for control, showing the control flow, 
and the DM modules to hold the result. Given the physical location of 
the modules, the diagram would represent a complete wiring diagram. 

The user may think of the structure as being analagous to entering 
a program subroutine and that is exactly how it was modeled in ALGOL - 
as a subroutine carrying out a conventional method of multiplication. 
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The operation is best explained by using the flow chart of the RTM 
description (Appendix D). In carrying out this algorithm, the multiplier 
is first placed in the right 16 bits of a 32 bit register, P<31:0>, 
composed of a 16 bit accumulator attached to a 16 bit multiplier register. 
The left 16 bits of this register are initially set to zero. The right- 
most bit of the register, P<0>, is then examined and if a "1" is con- 
tained therein, the 16 bit multiplicand is added to the left 16 bits of 
the register. The entire register is then shifted right one bit, and the 
righthand bit again examined. This process is carried out sixteen times 
and upon completion the 32 bit product is contained in the register. 

This product must then be scaled to the most significant 16 bits for 
further calculations. Additional information on this algorithm is 
available in Reference [3]. 

A 16 bit integer divider which divides to the nearest integer was 
also constructed for use in the program. The algorithm in this module 
(subroutine) was taken directly from that shown on page 201 of 
Reference [3]. The construction and operation of this module is very 
similar to that of the multiplier. 

Normal ALGOL W construction was used to simulate the hardwired 
versions of branching (Kbranch) and boolean (kboolean) operations. Other 
basic arithmetic operation modules such as square root, exponentiation, 
etc., can be easily constructed given the proper algorithm and the 
necessary Register Transfer Modules. 

C. FLOATING POINT MODULES 

Floating point arithmetic is a definite asset in solving certain 
classes of computer problems having a wide range of numerical values. It 
was therefore considered appropriate to demonstrate that floating point 

arithmetic vas possible using Register Transfer Modules. 
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The word length chosen for the floating point model was maintained 
at 16 bits for uniformity and was broken up as follows: 

Bit <15> the sign of the number. A"0" represented a 

positive number, "1" a negative. 

Bits <14:10> the exponent of the number. Both negative and 
positive exponents were possible using the 
following convention; 

00000 - 01111 negative exponents, 

10000 zero 

10001 - 11111 positive exponents. 

Bits <9:0> the two's complement representation of the 

mantissa. 

Floating point arithmetic is similar to integer arithmetic except 
that it must meet the following restrictions on operations with exponents 
(A X 2’') X (B X 2^) = (A X B) X 2’"'^^ 

(A X 2’") V (B X 2^) = (A T B) X 2^'^ 

(A X 2'^) + (B X 2’") = (A + B) x 7 ^ 

(A X 2'") - (B X 2'") = (A - B) X 2’^ 

In the latter two operations, it will usually be necessary to scale one 
of the numbers so that it's exponent equals the exponent of the other 
number. 

The floating point arithmetic modules were constructed using an 
appropriate combination of the previously discussed Register Transfer 
Modules. They simply consist of a set of modules for carrying out the 
proper exponent operations, a call to the appropriate integer arithmetic 
module to conduct the operation, and a scaling routine to reduce the 
result to the ten most significant bits and update the xponent, if 
necessary. 
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Appendix E contains a flowchart of the floating point "add" sub- 
routine. Similar floating point modules for the operations of subtrac- 
tion, multiplication and division were constructed and tested 
satisfactorily in the model. 

D. TRIGONOMETRIC MODULES 

Trigonometric operations, like the floating point operations, have a 
wide range of uses in today's modern digital computer. They are particu- 
larly useful in a majority of the airborne computer problems. Since one 
of the objectives of this paper is to show that there are possible uses 
for Register Transfer Modules in airborne computer systems, it was con- 
sidered appropriate to demonstrate how the modules can be used to com- 
pute trigonometric functions. The functions of sine, arcsine and 
arctangent were chosen for this demonstration since these are the opera- 
tions used in the triangulation problem discussed later in this paper. 

The algorithm for each of these modules consists of a set of basic 
integer modules combined to approximate the infinite series equations 
for the operation in question, with some constant modules intermixed for 
scaling operations. These scaled integer operations are used instead of 
using the floating point modules because of their simplicity. The scale 
used in these modules is dependent on the accuracy required for the 
particular application and can be modified accordingly. For the applica- 
tion presented in this paper, the calling fractional parameters were 

3 3 

multiplied by 10 , and the returned result was divided by 10 , thus, 

allowing all calculations to be accomplished in integer arithmetic, while 

maintaining a minimum accuracy of two significant digits to the right of 

the decimal point in any real number value. 

A RT diagram of the ALGOL simulated module for the ARCSIN is given 



in Appendix F. 
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IV. EXPERIMENTAL RESULTS 



A. GENERAL COMPUTING 

Figure 1 shows a diagram of a simple RTM program which computes the 
sum of the integers 0 to N. Figure 2 is the listing of the ALGOL 
program which simulates this simple algorithm. Several simple algorithms 
of this type were used to verify that the simulated modules worked pro- 
perly and were consistent with the principles and concepts of RTM 
operation in Reference [1]. 



CONTROL PART: DATA PART: 




Figure 1. Sum of Integers to N. 
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LISTING 



MEANING 



KSIMPLE(17); 

0VER:KSIMPLE(26); 



KSIMPLE(O); 
KSIMPLE(18); 
L: = TO; 



Set R1 to 0 
Set R2 to 0 



Select memory location 



KSIMPLE (6); 
KTEST (M); 



Rl mem(lO) 
R2 -f- R1 + R2 
Rl -e- Rl - 1 
TEST BUS s 0 



IF M = 0 THEN GO TO OVER; 



If false repeat loop, otherwise 
drop out of loop. 



Figure 2. Sum of Integers to N ALGOL Listing. 



B. SPECIFIC TASKS 

To demonstrate the use of the RTM system in specific task computing, 
the available RTMs were used to simulate a number of FORTRAN functions. 

Simple operations such as assignment, statements, branching, etc., were 
successfully demonstrated with little difficulty, since they only 
required simulation of a direct hardwired connection. A more complex 
operation of a FORTRAN machine which was simulated however, was the 
FORTRAN DO-LOOP. The system of RTM modules required to carry out this 
operation is given in Figure 3, with an explanation of the meaning 

attached to each of the steps in the algorithm. The successful completion 
of this algorithm was an indication that other operations of a FORTRAN 

machine, including subroutine calls, were within the capability of the 
RTM system. 

Other examples of the use of Register Transfer Modules in specific 
task computing were demonstrated in the construction of the floating point 
modules and in the tri angulation algorithm. 

C. TRIANGULATION 

The functional modularity of the RTM system allows a tremendous 
flexibility in the type of computer system that can be designed and it 
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was felt that this modularity could be useful in solving the problems 
presented in the AADC concept. 



LISTING 



MEANING 



CLEAR; 

L:=l; 

KSIMPLE(34) 

0VER:L:=0; 

KSIMPLE(17); 

+ 

statements 
to be executed 
in the loop 
+ 

KSIMPLE(26); 

L:=19; 

KSIMPLE(17); 

KSIMPLE (7); 

KSIMPLE (10); 

KIEST(M); 

IF M=0 then GO to OVER; 



set all registers to 0 
select memory location 
R2-Hnem(l); initial loop value 
select memory location 
Rl-HTiem(O); loop increment 



R2^R1 + R2 

select memory location 
R1 mem(19); loop end value 
R1 ^ R1 + 1 ; 

R1 ^ R1 - R2 
TEST BUS < 0 

If false repeat loop, otherwise 
drop out of loop. 



Figure 3. FORTRAN DO -LOOP RTM System. 



In order to further demonstrate the applicability of these modules 
to this specific task it was considered appropriate to model one of the 
more common airborne computer problems. The problem of "Tri angulation" 
was selected for this example. Tri angulation can be defined in this 
instance as the computation of the lead angle of intercept for a defen- 
sive weapons system (airborne or surface) on an approaching target. 

In the problem situation, the defensive weapon platform is considered 
to be in the center of a polar coordinate circle which is oriented to 
true north. All positions of the target are then measured relative to 
the center of the circle. Initiating the problem are any two successive 
inputs of a mark (range and bearing of the traget from the weapon plat- 
form, and time of the mark). Using these inputs, the proper trigonometric 
identities, and the Law of Sines, the program computes he true bearing on 
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which to direct the defensive weapon in order to intercept the target. 
The flowcharted algorithm is given in Appendix G. 

The algorithm was first coded in conventional ALGOL W using three 
different methods - the Law of Sines, the Law of Cosines and Successive 
Iteration. Successive Iteration is the computation of the firing bear- 
ing using the successive computation of the rate at which the target 
range and bearing are changing. The most efficient and accurate method 
was found to be the one using the Law of Sines, and thus it was adopted 
for the RTM system model . 

The triangulation model was coded and tested through all quadrants 
of the circle using the ALGOL modules of the simulated RTM system. In 
all cases, the solution computed by the model was fast and accurate. 

The solutions were generated by the model at an average rate of 3.93 
seconds of CPU time (IBM 360/57) per solution. It is estimated that the 
simulation model would, at best, be only one half as fast as the actual 
hardwired version of the system. It was not within the facility of the 
particular version of ALGOL W to measure the CPU time for each module. 
The average, CPU time however, for each executable statement in the 
algorithm was 28 mill i-seconds. Since each RTM module requires a sub- 
routine call and contains some executable statements, the execution time 
for each RTM is probably at least 28 mill i-seconds. Hardware versions 
that operate within these limits can easily be built, and thus the 
simulation model is considered a valid indicator of the minimum speed 
of solution. 

The solutions computed by the simulated RTM system were verified 
first by the "maneuvering board" method as described in Reference [4], 
and then by comparison with the solutions computed by he conventional 
ALGOL W programs. 
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All experimental results obtained in the configurations tested were 
considered representative of the expected performance of the actual RTM 
system, and appeared to be consistent with the concepts and principles 
of the actual system as described in Reference [1]. 
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V. CONCLUSIONS AND RECOMMENDATIONS 



The concept of using high level building blocks is not new. Various 
simulators, register transfer devices and other high level design aids 
are presently being developed. 

The implementation of this particular set of simple modules, though 
not unique, appears to be adequate and useful in many different areas. 
The modules can be applied easily and effectively to most problems with 
consistent results. The user need only be familiar with the concept of 
registers and register operations on data, and have a fundamental 
understanding of a flow chart in order to use RTM concepts. 

According to Reference [1], the hardwired modules described herein 
are fast, simple, efficient and accurate, and enjoy a significant cost 
advantage over alternate approaches to computer design. The results 
obtained with the simulated modules support all of these claims, except 
the last, which is obviously beyond the scope of simulation. The 
simulation of the simple FORTRAN machine and the other general purpose 
algorithms constructed in this project demonstrated that RTMs could be 
used in the implementation of other digital computer systems. The use 
of Register Transfer Modules in this capacity is therefore considered 
quite feasible, and allows significant flexibility in the design of 
these systems. All of these highly desirable characteristics should be 
considered in the design of any new digital computer system. 

The most significant finding of this project, however, was the 
feasibility and usefulness of these modules in specific task computing; 
in particular the RTM application to the Advanced Avio cs Digital 
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Computer proposal was impressive. The successful development of specific 
routines for trigonometric functions using RTMs was instrumental in the 
continuation of research in this area. The tri angulation problem modeled 
was highly successful in all respects. The RTM modules were effectively 
combined to carry out the complex algorithm, and in addition, the speed 
and efficiency achieved exceeded all expectations. Through this success- 
ful application of the RTM concept, a possible solution to the avionics 
computer problem has been found. 

A sufficiently high speed, low cost, modularized computer that can be 
configured to perform any task effectively and efficiently is available 
with the use of Register Transfer Modules. The discovery of additional 
applications for these modules is inevitable and it is highly recommended 
that additional research be performed in this area. A major step in this 
research might be to obtain actual modules for experimentation and 
construction of prototypes for an AADC. 
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APPENDIX A 



RTM MODULES 



K TYPE MODULES 



K(simp1e/sl e Kfsubroutine call /sc) 
X evoke/ev 



Ks (function evoked 
or subroutine 
called) 


evoke function/evfn 


^ evok.e_.function comolete/evfnc 







T 



evoke next/evn 



K(deci sion/d) 



"^evoke/ev 



Kd{ boolean 
condition) 



. Doolean 
b . . 

input 



evni /true/yes 



evnO/false/no 



K(bus sense/bus) 



b enable overflov/ set 
^0 



Bus-f- 



Human 



( stop switch 



Advance Kev 




b Overflow/ov ^ 

b Bus <15:0> ^ 

b Bus = 0 ^ 

evoke function complete 

e vfnc 

initializes ev ^ 



27 







% 



M TYPE MODULES 



M(array; core, read only, ic read-write) 











MA^ 


Marray 

Data avail ; 
Busy; 

MA<15:0> ; 
MB<15:0> 


b Busy 


MA-^; readvwrite^ 


b Data avail; ^ 


MA-^; read- 
pause-write 




MB^ 


-eMB 





M(boo1ean/b) 



B^O 


DMb 


B.i 




B -f-— 'B ^ 




B ^ I 


B 

optional 

optional 


I . b 


B -t- B©J 


J b 













B 









-► 
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Nl(qenera1 purpose arithmetic/gpa) 



T 



irA w 


dmgpa 


b A <15:0> 




b B <15:0> 


lA 




b Carry out/Co ^ 






(as separated 


^A + B ^ 




from overflow) 


^A - B 






^A - 1 






-t-A A B 








-t-A V B 








<-A© B 






^A + 1 


b 






^A X 2 


b 






-«-(result)/2 b^ 


Co; 




shift in 


<16,-1 >3 


A <15:0>; 




A- 


B <15:0> 

















Other Available Modules 



K type (control ) 

K(branch) 

K( serial merge) 
K(parallel merge) 
K(manual evoke) 
K(clock) 

K(delay) 



M type (memory) 

M(array ;core , read only, ic 
read-write) 



DM type (data memory) 

DM(consta;its/K) 
DM(transfer register/tr) 

T type (transducer) 

T( switch register/ sw) 
T(teletype) 

T(analog-to-digital/a-d) 
T(digital -to-analog/d-a) 
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APPENDIX B 



KSIMPLE AND GPA MODULE SIMULATION 



Listing of Ksimple 

PROCEDURE KSIMPLE( INTEGER VALUE J); 
BEGIN INTEGER I; 

I: = 1; 

IF J > 17 THEN BEGIN 

I: = 2; 

J: = J-17; 

END 

DA: = 1; 

DR: = 0; 

GPA(J); 

IF DR = 1 THEN GPA(I); 

END KSIMPLE; 



Comments 

DA and DR are global vari- 
ables. J values 1-17 
indicate the result is 
stored in R1 . 17-34 indicate 

result stored in R2. 

DA, DR are changed in the 
GPA if operations 
properly executed. 



Register Assignments (Values for I ) 

1 - R1 = BUS 

2 — R2 = BUS 



A rithmetic Operations (Values for J) 



0 - 


BUS 


= 


0 


9/26 - 


BUS 


= 


R1 + R2 


1/18 


- BUS 


= 


R1 


10/27 - 


BUS 


= 


R1 - R2 


2/19 


- BUS 


= 


R2 


11/28 - 


BUS 


= 


R1 A R2 


3/20 


- BUS 


= 


-R1 


12/29 - 


BUS 


= 


R1 V R2 


4/21 


- BUS 


= 


-•R2 


13/30 - 


BUS 


= 


R1 © R2 


5/22 


- BUS 


= 


-R1 


14/31 - 


BUS 


= 


R1 ^ R2 


6/23 


- BUS 


= 


Rl-1 


15/32 - 


BUS 


= 


R1 * 2 


7/24 


- BUS 


= 


Rl+1 


16/33 - 


BUS 


= 


R1 / 2 


8/25 


- BUS 


= 


R2+1 


17/34 - 


BUS 


= 


MEM(L) 
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Listing of GPA 



PROCEDURE GPAdNTEGER VALUE RESULT I); 

BEGIN 

IF I>0 THEN 
BEGIN 

IF DR=1 THEN 
BEGIN 

CASE I OF BEGIN 
R1 :=BUS; 

R2:=BUS; 

END; 

DR:=0; 

DA;=1; 

END 

ELSE 

BEGIN INTEGER SW; BITS TEMP; 

CASE I OF BEGIN 
BUS:=R1 ; 

BUS:=R2 

BUS: = (R1 AND #10000) OR (-R1 AND #FFFF); 

BUS: = (R2 AND #10000) OR hR2 AND #FFFF) ; 

BEGIN 

ADDER(#0,R1 ,#1 ,TEMP); 

BUS:=TEMP; 

END; 

BEGIN 

ADDER(R1 ,#2,#1 JEMP); 

BUS:=TEMP; 

END; 

BEGIN 

ADDER(R1 ,#2,#0,TEMP); 

BUS:=TEMP; 

END; 

BEGIN 

ADDER (R2, #2, #0, TEMP) ; 

BUS:=TEMP; 

END; 

BEGIN 

ADDER(R1 ,R2,#0,TEMP); 

BUS:=TEMP; 

END; 

BEGIN 

ADDER(R1 ,R2,#1 JEMP); 

BUS:=TEMP; 

END; 

BUS:=R1 AND R2; 

BUS*~R1 OR R2 ’ 

BUS: = (R1 AND-R2 AND #1FFFF) OR (-R1 AND R2 AND #1FFFF); 
BEGIN 
I;=0; 

END; 
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BEGIN 

TEMP:=(R1 SHR 16) AND #1; 
BUS:=(TEMP SHL 16) OR (R1 SHL 1 ) ; 
END; 

BEGIN 

TEMP:=(R1 SHR 16) AND #1; 

BUS:=(R1 SHR 1) OR (TEMP SHL 16); 
END; 

BUS:=MEM(L); 

END; 

DA:=0; 

DR:=1; 

END; 

END 

ELSE BEGIN 

R1 :=#0; 

DR:=0; 

DA:=1; 

END; 

END GPA; 
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APPENDIX C 



DIAGRAM OF FULL ADDER 




'r XC + YC + XY j 

CARRY SUM 

C(XC + YC + XY)' + XYC] (X + Y + C)= 

X'Y'C + X'YC + XY'C + XYC 
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APPENDIX D 



RTM DIAGRAM OF 16 BIT MULTIPLER 




At entry Multipler := P<15:0>; P<31:16>: = 0; or 



1 0 


MULTIPLIER 


31 


16 15 0 


Multiplicand: = 


MPD<31:16>; MPD<15:0>; 


1 .MPD_ 


0 1 


31 


16 15 0 



15 0 

RESULT; = P<31 :0> at exit 
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APPENDIX E 



FLOATING POINT ADDITION 




RETURN 
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APPENDIX F 

RTM DIAGRAM FOR ARCS IN 



RT DIAGRAM (Control Part Only) 
Control Part 




Connections to BUS, GPA, Memory, etc. is similar to that shown in 
Appendix D. 
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LISTING OF PROCEDURE ARCSIN 



BITS PROCEDURE ARCSIN(BITS VALUE X); 
BEGIN BITS SQ, SUM, TOTAL, NUM, NUMLSl , 
NUMLS2, TNUM; 

ADDER (X,#A,#0,X); 
KDIVIDE(X,BINRY(10)); 

SQ:=X; 

KTIMES(SQ,X); 

ADDER(Sq,#64,#0,SQ); 

KDIVIDE(SQ,BINRY(100)); 

SUM:=BINRY(100); 

KDIVIDE(SUM,BINRY(81)); 

R1 :=SQ; 

KDIVIDE(R1 ,BINRY(121)) 

ADDER(SUM,R1,#0,T0TAL); 

NUM:=BINRY(9) 

LOOP:TNUM:=NUM; 

ADDER(NUM,#2,#1 ,NUMLS1), 
KTIMES(NUM,SQ); 

KDIVIDE(NUM,NUMLS1); 

KTIMES( NUM, TOTAL); 
ADDER(NUM,#64,#0,NUM); 
KDIVIDE(NUM,BINRY(100)); 
SUM:=BINRY(100); 

ADDER(NUHLSi ,#2,#1 ,NUMLS2); 

KTIMES(NUMLS2,NUMLS2); 

KDIVIDE(SUM,NUMLS2); 

ADDER(NUM, SUM, #0, TOTAL); 
ADDER(TNUM,#4,#1 ,NUM); 

IF NUM=#1 THEN GO TO FINI; 

GO TO LOOP; 

FINI;KTIMES(TOTAL,X); 

ADDER(TOTAL ,#14, #0 , TOTAL ) ; 
KDIVIDE(T0TAL,BINRY(10)); 

TOTAL 

END ARCSIN; 
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APPENDIX G 

TRIANGULATION ALGORITHM 



The Algorithm 



target 




defensive platform 



intercept bearing 
T 




FIRST STAGE 



SECOND STAGE 



First Stage - Compute relative course and speed of target using 
two inputs of range and bearing of target, time 
between inputs and trigonometry functions SINE, 

ARCS IN and ARCTAN. 

Second Stage - Compute Intercept Bearing using relative course and 
speed of target, relative speed of intercept weapon 
and Law of Sines. 
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The Flowchart 







STAGE 1 









STAGE 2 



J 
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